home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 821 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.6 KB

  1. From: Eric Newhuis <newhuis@ix.netcom.com>
  2. Message-ID: <31523072.69D3@ix.netcom.com>
  3. X-Original-Date: Thu, 21 Mar 1996 22:45:38 -0600
  4. Path: in2.uu.net!bounce-back
  5. Date: 22 Mar 96 06:54:35 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Using pointers after delete
  9. Organization: FutureSource
  10. References: <4irkhs$8al@crchh327.rich.bnr.ca>
  11. X-Netcom-Date: Thu Mar 21  8:47:58 PM PST 1996
  12. X-Mailer: Mozilla 2.0 (Win95; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMVJOt+EDnX0m9pzZAQEqPAF/cX9rCL+V3TRwHJ2GsetvBqOSAZ5OSANh
  15.     iIUkW8Ze0Bq2ZcQUzVC9gs7RNMBOMbo/
  16.     =OCOb
  17.  
  18. joe (j.) halpin wrote:
  19. > char *pc = new char[128];
  20. > delete pc;
  21. > pc = 0;
  22. > Am I misunderstanding something, or is it illegal to zero out pointers
  23. > after they've been deallocated? I'm assuming that the intent was to
  24. > disallow dereferencing of pointers that have been handed to
  25. > delete. The wording seems to disallow the above as well.
  26.  
  27. There is not problem using a pointer like that.  If you re-read the 
  28. working paper closely you'll notice that the following phrase:
  29.  
  30. "An invalid pointer con-tains an unusable value:  it cannot even be used 
  31. in an expression."
  32.  
  33. is refering to the value of the pointer, not the pointer itself.  In 
  34. other words, replacing the value with zero is fine.
  35. ---
  36. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  37. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  38. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  39. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  40. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  41.